[scribus-dev] What to do?

[Craig Bradney]

On 2/25/11 6:15 PM, Gregory Pittman wrote:
> On 02/25/2011 11:49 AM, Craig Bradney wrote:
>> On 2/25/11 4:21 PM, a.l.e wrote:
>>> hi
>>>
>>> my point of view...
>>>
>>>
>>>> I have few improvements in my local Scribus 1.4 not published yet.
>>>> I would like to ask you, which patches and for which Scribus version
>>>> I should
>>>> upload and in what order?
>>>>
>>>> * [Preflight Verifier] widows/orphans check
>>> 1.4.1 + 1.5
>>>
>>>> * [Preflight Verifier] RGB text check
>>>
>>> 1.4.1 + 1.5
>>>
>>>> * [Preflight Verifier] progress bar indication during checking
>>>
>>> 1.5
>>>
>>>> * [Preflight Verifier] placing text cursor at CPos related to
>>>> selected error
>>>> item and automatically select whole paragraph for better visualition
>>>> region of
>>>> problem
>>>
>>> 1.4.1 + 1.5
>>>
>>>> * [ODT import] feature for omit whole paragraphs style information
>>>> (any new
>>>> styles are created, all text has Default Paragraph Style), but saving
>>>> local
>>>> character formatting
>>>
>>> 1.4.1 + 1.5
>>>
>>>
>>>> * [Status Bar] add information about selected item - kind of
>>>> item,frame name,
>>>> filename for image frames, dimensions
>>>
>>> we should have a good solution for showing information and avoid
>>> cluttering the status bar... imo...
>>>
>>>> * [Search/Replace] search and replace in whole document
>>>
>>> 1.4 / 1.4.1 + 1.5 (depending on how invasive it is)
>>>
>>>
>>>> * [Style Manager] set default style for replacing during deleting
>>>> styles to
>>>> "Deafult Paragraph Style" instead No Style
>>>
>>> 1.4
>>>
>>>> * [Properties Palette] tabs switching automaticaly related to
>>>> selected item
>>>
>>> 1.4.1? (will not be needed anymore in 1.5, since there won't probably
>>> be tabs anymore)
>>>
>>>> * [Properties Palette] applying Paragraph Style dont clear local
>>>> character
>>>> formatting (need some fix for proper behaviour while opening old SLA
>>>> files)
>>>
>>>
>>> 1.4.1, if it's possible to make it work with old SLAs
>>>
>>>
>>>     *
>>> *     *
>>>
>>> but all depends on how long 1.4 will be around...
>>>
>>> if we don't want any new feature in 1.4.x and 1.6 is planned for some
>>> time next year (i hope it's planned for next year!) all the changes
>>> marked as 1.4.1 can be directly applied to 1.5 only.
>>>
>>>
>>> ... just my 2mio francs...
>>
>> Putting versions against these is a bit early. We need to see bugs with
>> diffs for each change. Once we see the diff, we can see the complexity
>> of the change, and therefore judge the impact. Low impact might mean ok
>> for 1.4.1.
>>
>> And yes, 1.6 should be released next year, at a guess. No reason why
>> not.
>
> In the bigger picture, is there any possibility that sometime in the
> future, we might see a 'hard' release cycle, e.g. every 6 months, 9
> months..., in which we say, 'Even if we might have to delete
> incomplete new features, we will release a new, workable version in
> this timeframe'?
>
> I think what this adds to a project is a credibility, and perhaps
> soothes the teeming masses. To delay a new release a week or two is I
> think tolerable, but when delays seem to have no boundary the natives
> become restless.

We said we would do that at LGM about 3 years ago. A few of our devs'
lives have changed in that time.. and our team is small.. so that's
where it is at. We have had a number of features started but not
finished and then had to be slowly recovered. If we could all be more
active, then I expect that to happen. The more contributors to test,
patch, etc, the more that will happen, and the more releases will
happen. Many times, once code is in, reversing it becomes next to
impossible once it gets to a certain point.

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110225/710f08a3/attachment.pgp>