DECLRATION OF RESULTS: Voting rules documents
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
D E C L A R A T I O N O F R E S U L T S
1st vote October 8th, 2015
Hi everyone,
because I was busy I forgot to properly end the 1st vote as announced on
2015-10-01. So here is the formal declaration of results for the 1st
vote regarding the voting document.
History
°°°°°°°
- - 2015-08-15: Announcement of Vote: <87wpww6083.fsf(a)hades.cable.internal.west-ik.de>
- - 2015-09-30: Call for Votes: <87io7u39e0.fsf(a)hades.cable.internal.west-ik.de>
- - 2015-10-08: Declaration of results: (this message)
Vote subject
°°°°°°°°°°°°
This vote is aimed at the ratification of the voting rules document
itself.
Proponent
°°°°°°°°°
The voting was proposed by me, Quintus <quintus(a)quintilianus.eu>.
Votes
°°°°°
Option 1: Accept the voting rules document (6 votes, 75%)
Option 2: Reject the voting rules document (0 votes, 0%)
Abstained: 2 people, 25%
The vote had a special majority requirement; as per §21 of the voting
rules document it required at least ⅔ (approx. 66,6667%) of all team
members in favour of option 1. This majority has been reached. A
sufficient number of people participated.
Results
°°°°°°°
Option 1 has been ACCEPTED with the required majority. It is a binding
decision the team follows from now on, all cirstumstances being equal.
With regard to the vote subject this means that the voting document has
been accepted. Any further votes follow the procedure outlined in that
document.
Right to Complain
°°°°°°°°°°°°°°°°°
Every team member has the right to file a complaint against this formal
declaration. The complaint must be filed within 14 days from now on
(timestamp of this email) with either the project lead or with the
project assistant lead. The project lead and assistant lead must file
the complaint with one another; if both are involved, a volunteer must
be seeked for.
The complaint has to contain an explanation as to why the voting rules
have been violated. The person the complaint was filed with will then
check the procedure against the requirements of the voting rules
document, and if he finds a violation, he can declare the vote failed,
which allows repetition of the vote in question.
Other
°°°°°
I’m going to submit the accepted version of the voting rules document to
one of our online repositories, with the “draft” mark removed.
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWFnlqAAoJEPHYeZ+8yLxP3nYH/R/mQnxOMG9CMoKqnpefPhTT
k28Mj6QKt3RD7Xh1yeUlva5QrWVT1481LK1SJrk13Aqz44E0sjQlpnqtq0gqX2ou
xV7OXCz26RS45KQ3YhPCMGSORn7FjWT9CeSlseLtYjC5PiQgCBSFVsozDOG+Ifnx
8tYvT0Ow5rmxlZQn6GKGAqNaMDaGpNF7Uhh9ZFjGixuoe/qeV/Q/ZmTsoNQjPFJg
fkzkzSD3Izi7gXQB32HmymJxSr+BJrQDIgRY7+ntOnHSps0IT1KqGgCbC+SjVuXu
hQOvPCvkXYvX+hvyd+Q3/8kJrKdNTe09V1nMybHZq2d+ngO9KFIhAolReprI0r8=
=oO3s
-----END PGP SIGNATURE-----
4 years, 9 months
SFML and further development process
by Quintus
Hi everyone,
it has become evident that the SFML port is a huge work that will still
take a lot of time to be completed. Waiting for me doing it will slow
down progress quite heavily. I thus want to make this a high-priority
issue now and pursue it for one of the next releases, postponing each
and every other issue on the tracker until it is done. simpletoon, Luiji,
could you two please take a look at the SFML code I already wrote (and
documented), and tell me if you think you can familiarise yourself with
it, and then work on it together with me? The current state of affairs
is that everyone of us does some rather little things on his own, but
the SFML porting stuff is too large for me. I need help. And this means
we need to coordinate our work so we don’t get into one another’s way of
programming.
Once you looked at it, please file tickets on the tracker regarding all
tasks that you think are still pending, and tag them with the “SFML
port” tag. This will give us a list of tasks that are outstanding. We
then have to bring them into a useful dependency hierarchy (a shame that
GitHub’s tracker doesn’t properly support issue dependencies; we need to
simply put comments into the tickets), and then tackle them bottom-up
one-by-one. I think if we three work together to systematically cut this
down, we can succeed in a reasonable amount of time.
The key to managing this huge task is the word “systematically”. Please
do not simply start something. Let us first create all the tickets, then
order them, and when this both is done, take whatever bottom-most task
in the dependency hierarchy is unassigned, assign it to you, and
implement it. It is desirable to have the tasks on the tracker be sized
such a way that one ticket does not take more than a week to implement
(roughly). This should allow everyone to get this into his free time,
and most importantly, it allows to finish one ticket and then abstain
for some time when real life issues are more important, afterwards then
a new one-week task can be picked up. That means, if you assign a ticket
with the “SFML port” tag to yourself, you have decided to dedicate the
next week to this issue. Do not assign it to yourself if you don’t know
whether you have time during the next week.
That’s the theory. I know some issues come out more difficult then they
go in. In that case please post a description of the problem into the
ticket, and consider extracting a subproblem into a new ticket, if
possible. If necessary, unassign yourself from the ticket again.
datahead, I only mentioned Luiji and simpletoon above, because they have
been rather quiet during the last time. However, of course you — and
likewise anybody else who is able to program — are invited to join these
efforts in getting the SFML port out of the door.
I am available for any questions regarding the SFML-related code. You
can find that code in the “feature-sfml-port” branch. I merged the
separate “sfml_level_loading” branch I worked on lately into that branch
to consolidate all SFML-related stuff into that one branch before we
start off our joint work so that it is easier to familiarise yourself
with the code. Please also read the documentation comments I left in the
code.
Please give feedback about this issue. We need to go forward.
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
4 years, 9 months
Fwd: [Quintus] Re: [tsc-devel] SFML and further development process
by Luiji Maryo
Let's see if this works...
Hey all, I was talking with Quintus in IRC and he asked me to put my
thoughts into the mailing list thread.
I'm pretty far on Quintus's side. This is a unique problem that needs
unique handling. The SFML port is major because it changes a huge
number of files. It's a fundamental change between drawing APIs.
However, it is one that can be done systematically, since OpenGL and
SFML code can be intermixed. It's also one that needs coordination,
since two people working on the same code can happen pretty easily and
waste time.
A feature-freeze is also pretty acceptable for the core team, since
the longer the SFML port changes, the longer the core base will
change, and after a certain amount of time we may end up in a place
where the SFML port needs to be redone because the code bases are too
far out of sync.
I would also like to note that the GUI change is likely more minor,
since it effects a smaller part of the code base (though it does still
effect a significant chunk).
I hope I'm all clear. I made sure to reread the thread right before
writing this so I didn't fall off-page, so hopefully I was successful
in that matter.
- Luiji
On Wed, Oct 7, 2015 at 8:16 AM, Quintus <quintus(a)quintilianus.eu> wrote:
>
>
> --
> #!/sbin/quintus
> Blog: http://www.guelkerdev.de
>
> GnuPG key: F1D8799FBCC8BC4F
>
>
> ---------- Forwarded message ----------
> From: Quintus <quintus(a)quintilianus.eu>
> To: tsc-devel(a)lists.secretchronicles.de
> Cc:
> Date: Tue, 06 Oct 2015 18:23:35 +0200
> Subject: Re: [tsc-devel] SFML and further development process
> datahead <automailer(a)forum.secretchronicles.de> writes:
>>> The SFML port is so complex nobody is going to work on it voluntaryly, but it needs to be done.
>>
>> No, it will probably not be easy to get people to volunteer, but I
>> just tend to be very hesitant about forcing options on contributors
>> when they are volunteering time.
>
> I think “forcing” is the wrong word. I am not going after anyone here if
> he doesn’t code, or code something different from what I suggested. But
> I deem it necessary to get a structured co-operation model set up that
> yields more than “everyone does whatever he feels like now”. It is a
> well-known fact that if multiple people work on the same thing, this
> thing gets finished more quickly, and usually better, as if only one
> works on it. If everyone just does whatever he wants, there is the high
> danger of unfinished stuff lying around.
>
> Let be clarify on my previous posting, because I think you misunderstood
> an important detail of my suggestion. I was not meaning to impose our
> internal co-operation model to occasional filers of pull requests,
> i.e. casual contributors. These will always be considered, regardless of
> what they choose to work on. What I am referring to is only the
> co-operation model of the TSC core team, i.e. those people who devote
> their time regularyly to the game.
>
>> Also, there will always be something like this that "needs" to be
>> done. Before this it was release 2.0 (which went for a long time)
>
> The SFML port is a fairly unique effort that will not show up in this
> nature again for years to come. A task of such dimensions is not going
> to reappear soon.
>
> However, you are of course correct that there’s always something that
> “needs” to be done. I think we should set up a more systematic
> co-operation model for these ordinary tasks also, but it shouldn’t look
> like the one I was suggesting for the SFML stuff. This model is more of
> an “emergency” model for the really pressing issues, and I could imagine
> that its activation should be subject of vote.
>
>> and after this it will either be the SFGUI port or CEGUI upgrade.
>
> You’ll grant me that this is so closely related to the SFML porting that
> I didn’t draw the difference. I think I could have labelled it “wiping
> out the 10-year old base code from TSC”, but “SFML port” was more terse
> :-)
>
> I do not think that this issue (it actually is only one, as they’re
> exclusive to one another) is so large as exchanging all our
> input handling code. We can return to our usual, more liberal
> co-operation model for these.
>
>> On one last note, my Doom Larry feature was ready before any such lock
>> down started. I would at least like to put it in devel.
>
> You are absolutely free to do that. I mentioned previously already that
> we have to make up all the SFML tasks in the tracker first anyway, so
> until that is done you have of course time to merge everything relevant
> into devel.
>
> Valete,
> Quintus
>
> --
> #!/sbin/quintus
> Blog: http://www.guelkerdev.de
>
> GnuPG key: F1D8799FBCC8BC4F
>
>
4 years, 9 months
First try at porting to Mac, and a linker error
by Tobbi
Post via forum by Tobbi <tobbi@xxxxxxxxxx>:
Hello everyone,
I am trying to get TSC running on Mac (without Wine), and have started porting it. Whether it works or not, I cannot tell yet. However, you can find my changes here:
https://github.com/Secretchronicles/TSC/compare/devel...tobbi:fix_mac_com...
In any case: I keep getting a linker error, that looks like this:
[ 1%] Linking CXX executable tsc
ld: library not found for -lSDLmain
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [tsc] Error 1
make[1]: *** [CMakeFiles/tsc.dir/all] Error 2
make: *** [all] Error 2
--
Sent by Chessboard.
4 years, 9 months
Self-hosting the project
by Quintus
Hi everyone,
I. Overview
as has been disussed before in IRC for months, we want to switch our
project infrastructure completely over to alexandria, because GitHub
1) asks people to censor stuff
2) is not an open platform
3) tries to get a monopoly
4) may change their business model affecting all depandent projects
5) more reasons we mentioned in IRC I can’t think of right now.
For this to happen, we’re going to have to choose a project management
software setup. There will be quite some stuff for sydney to learn
during that course :-)
II. Requirements
It is fairly obvious that we’re going to host a Git daemon (see
git-daemon(1)) for read-only access to our repositories, but apart from
that we need to select the software we want. Before making suggestions
for that, we need to determine what we actually need. Looking at the
project, I think I derived the following requirements:
1. Repository source browser, including Git revision history. Best if it
contains syntax highlighting.
2. Ticket system, for bugs, feature requests, pull requests.
There are more requirements, but our existing infrastructure already
satisfies them:
3. Wiki for community content (Moinmoin).
4. Mailing lists and forum, best interconnected (mlmmj, Chessboard)
5. Main website including news posts with RSS (static HTML).
6. File upload/download facility for releases and for every team member
(project FTP and SFTP services).
I think points 4-6 work well enough that there’s no need to replace
them. If the software we chose has such facilities, they’d thus have to
be disabled; on the other hand, if it doesn’t have such facilities, this
is fine.
Point 3 is an eternal source of frustration currently. The old Moinmoin
wiki version we have wreaks havoc every now and then, requiring a hard
restart of the apache httpd daemon each time. Newer versions of Moinmoin
may not have that issue, so we shouldn’t ditch it without further
thought.
Regarding the tickets, GitHub appears to have a fairly good API that
allows to programmatically retrieve these[1]. The ticket system we use
should thus allow for automated import of existing tickets of some kind;
a quick one-time hack suffices. We won’t do that more often than once,
and can then forget about that. Writing a little script that fetches the
tickets from GitHub’s API and importing them into the new system
shouldn’t be too much effort.
Since our server sponsor extended our server’ſ capabilities a lot
(thanks for that again), we will have no resource shortage.
III. Software
I will not use Mantis.
Okay, that being said, the following software comes to mind. This list
is neither meant to be exhaustive, nor exclusive; there is more
software out there, and we may run some of these in parallel. Please
discuss.
1) Redmine: http://www.redmine.org/
2) Bugzilla: https://www.bugzilla.org/
3) Git’s builtin-repository browser, Gitweb.
4) Trac: http://trac.edgewall.org/
5) Flyspray: http://www.flyspray.org/
6) Selfhosted Gitlab: https://gitlab.com
I have experience with Redmine, and can say that it has some nice
features (like customisable ticket statuses, subprojects, private
projects and a milestone system. It is written in Ruby and licensed as
GPL, which is why I have a slight preference towards this.
Bugzilla (written in Perl, licensed as MPL) is known to very nicely
integrate with mailinglists for discussion and with bugzilla.mozilla.org
there is a really large power-user of this software that guarantees it
is rock-solid. I’d absolutely be fine with this one; Bugzilla to my
knowledge only provides the ticket system, though, so no builtin
repository browser (but there are separate ones like Gitweb). AFAIK
RedHat also uses Bugzilla for their bugtrackers.
Gitweb recently got syntax highlighting, so don’t say we can’t use it
because it has none. This should be considered if we use a tickets-only
software like Bugzilla or Flyspray. Gitweb is written in C and comes
with Git itself.
Trac is similar to Redmine, but I have never used it. It’ſ Python
software under the BSD license. Can someone elaborate?
Flyspray like Bugzilla is only a ticket system. It was used by our
server sponsor (now replaced by their own solution) and by the ArchLinux
development team. No stable release since 2012, though. PHP software,
but I was unable to determine the license.
Gitlab is basically like GitHub. It even looks similar. The software is
written in Ruby and licensed under BSD; you must sign a CLA to
contribute. Note Gitlab is a commercial company (not necessaryly bad),
and the version one can selfhost is a stripped-down “community
version”. Gitlab recently bought and shut down the popular Gitorious
service, which was a free (GPL!) alternative to GitHub. This generated a
lot of critical comments on their announcement, which they appear to
have simply deleted by now. I don’t want to work with a company with
such an attitude.
These are the things that come to my mind; Bugzilla and Flyspray are
lightweight solutions that only solve one problem and nothing more; the
others are fully-fledeged project management software programs that try
to be the one-size-fits-all solution. I have a preference towards
Redmine or Bugzilla, but please feel free to discuss the issue. Also
please mention more software, even if it is not directly related to the
core infrastructure.
Valete,
Quintus
[1]: https://developer.github.com/
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
4 years, 9 months
Minor release for the crash bug?
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Assuming the crash bug is verified in the 2.0 game executable, I propose we have a minor release to fix it. About all of the people who have played release 2.0 have reported this issue and referred to the game as buggy. In some cases, people are having difficulty playing the first level at all. I had seen this issue myself in the release candidate. I would not feel comfortable sending release 2.0 to a Linux distribution if it is not stable, and of course we need to get it in Linux distributions in order to draw more people to the project. Thus I view the issue as critical.
The SFML port, important as it is, will take more time to complete, even with more volunteers starting work on this. Having a stable release out during this time frame would open more doors toward getting people involved in the project, which is its life blood.
What does everyone think?
--
Sent by Chessboard.
4 years, 9 months
