2 Nov
2011
2 Nov
'11
3:27 p.m.
Hello all,
Good work team, and thank you to everyone who helped with the release!
Now that the release is out the door, we are looking ahead to the next
release. At this meeting we will discuss our goals and our ideas for
3.5.14. If everyone could start to thinking about what they would like to
do, or see done for 3.5.14 that would be great. Please bring your thoughts
to the meeting.
Please checkout the following links and contribute as such:
Roadmap for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Roadmap
Release Goals for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Release_Goals
Etherpad for November Meeting: http://trinity.etherpad.trinitydesktop.org/15
This meeting is for everyone interested helping trinity desktop. That
means, Packagers, Contributors, Developers, and even Users! If you are
interested in getting involved and don't know where to start, please come
to this meeting to find out how you can help!
There will more detailed time information as we draw closer to the meeting.
The meeting will probably occur in the early evening EST.
Please RSVP and let us know if you can/cannot make it.
Thank you,
Calvin Morrison
Trinity Desktop Team.
2 Nov
2 Nov
5:55 p.m.
New subject: [trinity-devel] November: Post Release Meeting 11/15/2011
Hello all,
Good work team, and thank you to everyone who helped with
the release!
Now that the release is out the door, we are looking ahead
to the next release. At this meeting we will discuss our
goals and our ideas for 3.5.14. If everyone could start to
thinking about what they would like to do, or see done for
3.5.14 that would be great. Please bring your thoughts to
the meeting.
Please checkout the following links and contribute as
such:
Roadmap for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Roadmap
Release Goals for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Release_Goals
Etherpad for November Meeting: http://trinity.etherpad.trinitydesktop.org/15
I still need to create 3.5.13 packages for Slackware, which means I'm not even out of
the starting gate yet. :( I believe there is another person who has created packages for
Slackware, so I am not anticipating significant problems. My schedule still has not opened
as I want. If I am unable to create binary packages real soon now, perhaps that other
person can upload Slackware binary packages?
The Trinity Paper Cut project never got officially launched after 3.5.12. I would like to
see that project receive official attention. Many bugs were quashed for 3.5.13, but I
can't test any bug reports I filed until I build and install packages. I have received
only a few notices that any of the bug reports I filed received attention.
I would like to see a relatively dependable 6 month release cycle. Maybe even one or two 3
month cycles until the Paper Cut project significantly reduces the bug list. That means
biting only what can be chewed.
The cmake port was unexpected and caused a long delay in the 3.5.13 release. That kind of
regular delay will be bad for public relations. If 3.5.14 and 3.5.15 focused on bug
quashing and each was released in a 3 month cycle, that keeps Trinity in the news and
shows potential users that developers are serious.
I am not asking for a rapid release cycle. Only to consider a couple of quick releases
that focus entirely on serious bug quashing.
The 3.5.14 road map implies about 30 days of bug quashing before migrating to GIT.
That's good.
I imagine the shift from SVN to GIT will require a one-time massive download to create and
initialize a local GIT tree. I imagine the new GIT tree will be about the same size as the
SVN tree and will be 4 to 5 GB in size. That translates into a long download session for
many people. Is there a way to convert a local SVN tree to GIT without the long download?
Build scripts will need to be modified to support building from the new GIT tree.
Therefore there is some work involved for any packager or developer to migrate to GIT. The
road map indicates the code repository will remain frozen until the transition to GIT is
complete and that is a good idea. The code base should remain frozen until a few of the
more talented developers have modified and tested their build scripts for the new GIT tree
so they can help others do the same.
The road map indicates "code hacking" will begin after the migration to GIT.
Does that mean focusing on enhancement requests in the bugzilla?
Possibly for public relations and keeping Trinity in the news, 3.5.14 could focus only on
bugs and GIT and release in 3 months. Postpone enhancement requests and
"hacking" until 3.5.15?
Darrell
6:09 p.m.
New subject: [trinity-devel] November: Post Release Meeting 11/15/2011
Le Wed, 2 Nov 2011 10:55:34 -0700 (PDT),
Darrell Anderson <humanreadable(a)yahoo.com> a écrit :
If you are talking
about me, I didn't build anything beyond
kdelibs/kdebase, and had a build failure with kdepim (but I didn't try
to figure if there is really a problem or if this is just because of
the kdelibs/kdebase being 2 months older than the kdepim I tried to
build). Furthermore, which Slackware version are you talking about ? I
didn't do anything on Slackware 13.1 since my only powerful machine is
on single-boot Slackware64 13.37.
Hello all,
Good work team, and thank you to everyone who helped with
the release!
Now that the release is out the door, we are looking ahead
to the next release. At this meeting we will discuss our
goals and our ideas for 3.5.14. If everyone could start to
thinking about what they would like to do, or see done for
3.5.14 that would be great. Please bring your thoughts to
the meeting.
Please checkout the following links and contribute as
such:
Roadmap for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Roadmap
Release Goals for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Release_Goals
Etherpad for November Meeting:
http://trinity.etherpad.trinitydesktop.org/15
I still need to create 3.5.13 packages for Slackware, which means I'm
not even out of the starting gate yet. :( I believe there is another
person who has created packages for Slackware, so I am not
anticipating significant problems. My schedule still has not opened
as I want. If I am unable to create binary packages real soon now,
perhaps that other person can upload Slackware binary packages?
The Trinity Paper Cut project never got officially launched after
3.5.12. I would like to see that project receive official attention.
Many bugs were quashed for 3.5.13, but I can't test any bug reports I
filed until I build and install packages. I have received only a few
notices that any of the bug reports I filed received attention.
I would like to see a relatively dependable 6 month release cycle.
Maybe even one or two 3 month cycles until the Paper Cut project
significantly reduces the bug list. That means biting only what can
be chewed.
The cmake port was unexpected and caused a long delay in the 3.5.13
release. That kind of regular delay will be bad for public relations.
If 3.5.14 and 3.5.15 focused on bug quashing and each was released in
a 3 month cycle, that keeps Trinity in the news and shows potential
users that developers are serious.
I am not asking for a rapid release cycle. Only to consider a couple
of quick releases that focus entirely on serious bug quashing.
The 3.5.14 road map implies about 30 days of bug quashing before
migrating to GIT. That's good.
I imagine the shift from SVN to GIT will require a one-time massive
download to create and initialize a local GIT tree. I imagine the new
GIT tree will be about the same size as the SVN tree and will be 4 to
5 GB in size. That translates into a long download session for many
people. Is there a way to convert a local SVN tree to GIT without the
long download?
Build scripts will need to be modified to support building from the
new GIT tree. Therefore there is some work involved for any packager
or developer to migrate to GIT. The road map indicates the code
repository will remain frozen until the transition to GIT is complete
and that is a good idea. The code base should remain frozen until a
few of the more talented developers have modified and tested their
build scripts for the new GIT tree so they can help others do the
same.
The road map indicates "code hacking" will begin after the migration
to GIT. Does that mean focusing on enhancement requests in the
bugzilla?
Possibly for public relations and keeping Trinity in the news, 3.5.14
could focus only on bugs and GIT and release in 3 months. Postpone
enhancement requests and "hacking" until 3.5.15?
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
3 Nov
3 Nov
5:29 p.m.
New subject: [trinity-devel] November: Post Release Meeting 11/15/2011
Le Wed, 2 Nov 2011 19:09:45 +0100,
/dev/ammo42 <mickeytintincolle(a)yahoo.fr> a écrit :
Le Wed, 2 Nov 2011 10:55:34 -0700 (PDT),
Darrell Anderson <humanreadable(a)yahoo.com> a écrit :
If you are talking
about me, I didn't build anything beyond
kdelibs/kdebase, and had a build failure with kdepim (but I didn't try
to figure if there is really a problem or if this is just because of
the kdelibs/kdebase being 2 months older than the kdepim I tried to
build). Furthermore, which Slackware version are you talking about ? I
didn't do anything on Slackware 13.1 since my only powerful machine is
on single-boot Slackware64 13.37.
For kdepim, the build fails with today's SVN
because of broken
Slackware libical package: kludging a supplemental
"-I/usr/include/libical" (I did it with the libical.pc file but it can
be made in the build script) makes kdepim build fine.
Hello
all,
Good work team, and thank you to everyone who helped with
the release!
Now that the release is out the door, we are looking ahead
to the next release. At this meeting we will discuss our
goals and our ideas for 3.5.14. If everyone could start to
thinking about what they would like to do, or see done for
3.5.14 that would be great. Please bring your thoughts to
the meeting.
Please checkout the following links and contribute as
such:
Roadmap for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Roadmap
Release Goals for 3.5.14:
http://www.trinitydesktop.org/wiki/bin/view/Developers/3_5_14_Release_Goals
Etherpad for November Meeting:
http://trinity.etherpad.trinitydesktop.org/15
I still need to create 3.5.13 packages for Slackware, which means
I'm not even out of the starting gate yet. :( I believe there is
another person who has created packages for Slackware, so I am not
anticipating significant problems. My schedule still has not opened
as I want. If I am unable to create binary packages real soon now,
perhaps that other person can upload Slackware binary packages?
The Trinity Paper Cut project never got officially launched after
3.5.12. I would like to see that project receive official attention.
Many bugs were quashed for 3.5.13, but I can't test any bug reports
I filed until I build and install packages. I have received only a
few notices that any of the bug reports I filed received attention.
I would like to see a relatively dependable 6 month release cycle.
Maybe even one or two 3 month cycles until the Paper Cut project
significantly reduces the bug list. That means biting only what can
be chewed.
The cmake port was unexpected and caused a long delay in the 3.5.13
release. That kind of regular delay will be bad for public
relations. If 3.5.14 and 3.5.15 focused on bug quashing and each
was released in a 3 month cycle, that keeps Trinity in the news and
shows potential users that developers are serious.
I am not asking for a rapid release cycle. Only to consider a couple
of quick releases that focus entirely on serious bug quashing.
The 3.5.14 road map implies about 30 days of bug quashing before
migrating to GIT. That's good.
I imagine the shift from SVN to GIT will require a one-time massive
download to create and initialize a local GIT tree. I imagine the
new GIT tree will be about the same size as the SVN tree and will
be 4 to 5 GB in size. That translates into a long download session
for many people. Is there a way to convert a local SVN tree to GIT
without the long download?
Build scripts will need to be modified to support building from the
new GIT tree. Therefore there is some work involved for any packager
or developer to migrate to GIT. The road map indicates the code
repository will remain frozen until the transition to GIT is
complete and that is a good idea. The code base should remain
frozen until a few of the more talented developers have modified
and tested their build scripts for the new GIT tree so they can
help others do the same.
The road map indicates "code hacking" will begin after the migration
to GIT. Does that mean focusing on enhancement requests in the
bugzilla?
Possibly for public relations and keeping Trinity in the news,
3.5.14 could focus only on bugs and GIT and release in 3 months.
Postpone enhancement requests and "hacking" until 3.5.15?
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read
list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
2 Nov
2 Nov
6:10 p.m.
New subject: [trinity-devel] November: Post Release Meeting 11/15/2011
The Trinity Paper Cut project never got officially launched after 3.5.12.
I would like to see that project receive official attention. Many bugs were
quashed for 3.5.13, but I can't test any bug reports I filed until I build
and install packages. I have received only a few notices that any of the
bug reports I filed received attention.
Dealing with bugs is one of the main priorities for this release. Sadly the
last release was rushed out the door. While something like 40+ bugs were
squashed, there are many more to deal with.
I would like to see a relatively dependable 6 month release cycle. Maybe
even one or two 3 month cycles until the Paper Cut project significantly
reduces the bug list. That means biting only what can be chewed.
3 Month cycles are no feasible. It takes 6 weeks to do testing and QA, not
much time to deal with anything improvement wise.
6 months seems to be the generally accepted release schedule, and it fits
in similarly with the release schedule of other projects in the F/OSS
ecosystem. Planning for a 6 month release gives us time to do what we need
to do and have a good release
The cmake port was unexpected and caused a long delay
in the 3.5.13
release. That kind of regular delay will be bad for public relations. If
3.5.14 and 3.5.15 focused on bug quashing and each was released in a 3
month cycle, that keeps Trinity in the news and shoDarrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
ws potential users that developers are serious.
We veered off the 6 month cycle one time, I think it would not be good to
do 3 month releases.
I am not asking for a rapid release cycle. Only to consider a couple of
quick releases that focus entirely on serious bug
quashing.
Lets have one really good release and squash them all :)
The 3.5.14 road map implies about 30 days of bug
quashing before migrating
to GIT. That's good.
I imagine the shift from SVN to GIT will require a one-time massive
download to create and initialize a local GIT tree. I imagine the new GIT
tree will be about the same size as the SVN tree and will be 4 to 5 GB in
size. That translates into a long download session for many people. Is
there a way to convert a local SVN tree to GIT without the long download?
you'll probably have to just download it, sorry :[
Calvin Morrison
7:08 p.m.
New subject: [trinity-devel] November: Post Release Meeting 11/15/2011
On Wed, Nov 2, 2011 at 13:55, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I imagine the shift from SVN to GIT will require a
one-time massive download to create and initialize a local GIT tree. I imagine the new GIT
tree will be about the same size as the SVN tree and will be 4 to 5 GB in size. That
translates into a long download session for many people. Is there a way to convert a local
SVN tree to GIT without the long download?
IIRC the plan is to split Trinity into separate git repositories, but
not fully confirmed yet.
We'll work it out closer to migration date.
--
later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu
3 Nov
3 Nov
1:46 p.m.
In article <1320256534.11880.YahooMailClassic(a)web161404.mail.bf1.yahoo.com>om>,
Darrell Anderson <trinity-devel(a)lists.pearsoncomputing.net> wrote:
The Trinity Paper Cut project never got officially
launched after
3.5.12. I would like to see that project receive official attention.
Many bugs were quashed for 3.5.13, but I can't test any bug reports I
filed until I build and install packages. I have received only a few
notices that any of the bug reports I filed received attention.
Though I only dabble on the development side I'd like to support this
view. 3.5.13 is a superb piece of work with many improvements, and I
am running it on my main stable machine which says something about my
trust for it. Congratulations to everyone involved !
But a few regressions have crept into 3.5.13, particularly my Javascript
one which is turning out to prevent quite a number of AJAX based sites
from working, and one or two others that also seem to be related to cmake
not picking up libraries (haven't bugged them yet as I have been busy
this week). I think these may disappoint people who come to Trinity as
the JS one at least is quite visible.
I'm certainly willing to help on a 3.5.13.1 "papercut" release and feed
the fixes forwards to the main branch, to leave the main devs free to
tackle features in 3.5.14.
Nick
--
Serendipity: http://www.leverton.org/blosxom (last update 29th March 2010)
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996
4:09 p.m.
New subject: [trinity-devel] Re: November: Post Release Meeting 11/15/2011
In article
<1320256534.11880.YahooMailClassic(a)web161404.mail.bf1.yahoo.com>om>,
Darrell Anderson <trinity-devel(a)lists.pearsoncomputing.net> wrote:
I would not be opposed to a single SRU for the 3.5.13 kdebase module, as
that is where most of the regressions seem to be centered. I have started
an Etherpad to keep track of proposed changes in the SRU here:
http://trinity.etherpad.trinitydesktop.org/16
If you don't have an Etherpad account just request one.
Tim
The Trinity Paper Cut project never got officially
launched after
3.5.12. I would like to see that project receive official attention.
Many bugs were quashed for 3.5.13, but I can't test any bug reports I
filed until I build and install packages. I have received only a few
notices that any of the bug reports I filed received attention.
Though I only dabble on the development side I'd like to support this
view. 3.5.13 is a superb piece of work with many improvements, and I
am running it on my main stable machine which says something about my
trust for it. Congratulations to everyone involved !
But a few regressions have crept into 3.5.13, particularly my Javascript
one which is turning out to prevent quite a number of AJAX based sites
from working, and one or two others that also seem to be related to cmake
not picking up libraries (haven't bugged them yet as I have been busy
this week). I think these may disappoint people who come to Trinity as
the JS one at least is quite visible.
I'm certainly willing to help on a 3.5.13.1 "papercut" release and feed
the fixes forwards to the main branch, to leave the main devs free to
tackle features in 3.5.14.
Nick
--
4568
days inactive
4569
days old
7 comments
6 participants
participants (6)
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Nick Leverton -
Robert Xu -
Timothy Pearson